home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Scene Storm
/
Scene Storm - Volume 1.iso
/
coding
/
c
/
vbcc
/
doc
/
vbcc.doc
< prev
next >
Wrap
Text File
|
1995-11-23
|
6KB
|
198 lines
vbcc - C compiler (c) in 1995 by Volker Barthelmann
INTRODUCTION
vbcc shall be a free portable ANSI compliant C compiler.
It is clearly split into a machine independant and a machine dependant
part and supports emulating datatypes of the target machine on any
other machine so that it is possible to e.g. make a crosscompiler for
a 64bit machine on a 32bit machine.
The machine independant part generates a form of intermediate code
(quads) which has to be dealt with by the code generator. This
intermediate code is rather cpu independant (apart from register usage),
but the machine independant part of vbcc uses informations about the
target machine while generating this code.
If You are interested in writing a code generator for vbcc, contact
me (the necessary documents are not written yet).
This document only deals with the machine independant parts of vbcc.
Be sure to read all the documents in the doc directory for Your machine.
LEGAL
vbcc is (c) in 1995 by Volker Barthelmann. All code is written by me
and may be freely redistributed as long as no modifications are made
and nothing is charged for it.
Non-commercial usage of vbcc is allowed without any restrictions.
Commercial usage needs my written consent.
Sending me money, gifts, postcards etc. would of course be very nice
and may encourage further development of vbcc, but is not legally or
morally necessary to use vbcc.
INSTALLATION
The installation is system dependant and covered in another manual.
USAGE
Usually vbcc will be called by a frontend. However if You call it
directly, it has to be done like this (and most of the options
will be passed through to vbcc by the frontend).
vbcc [options] file
At the moment file has to be an already preprocessed C source.
The following options are supported by the machine independant part
of vbcc:
-quiet do not print the copyright notice
-ic1 write the intermediate code before optimizing to file.ic1
-ic2 write the intermediate code after optimizing to file.ic2
-debug=n set the debug level to n
-noasm do not generate assembler output for code (only for testing)
-O=n turns optimizing options on/off; every bit set in n turns
on an option; see below
-ansi switch to ANSI mode;
at the moment this only affects warning/error messages;
in ANSI mode every warning with ANSI violation will be an
error and all other warnings are suppressed.
-maxerrors=n
abort the compilation after n errors; do not stop if n==0
-dontwarn=n
suppress warning number n
The assembler output will be saved to file.asm (if file already contained
a suffix, this will first be removed; same applies to .ic1/.ic2)
SOME INTERNALS
I try to make vbcc as ANSI compliant as possible (but this is not that
easy, because I do not have the ANSI document), so I am only mentioning
some things I consider interesting.
First, there still may be many many bugs, the compiler may crash, it may
generate incorrect code, accept incorrect sources etc. Also it does
almost no optimizing at the moment and is still very slow.
DATA TYPES
vbcc can handle the following data types:
signed/unsigned char/short/int/long (signed is always default)
float/double (long double is always the same as double)
However several of them can be identical in certain implementations.
OPTIMIZATIONS
At the moment the following bits in the -O option are recognized:
Bit 0 (1)
Use simple register allocation to assign variables to registers.
This improves the generated code quite a bit.
The effect on compile time is hard to predict, but it should be very
small - this optimization may even speed up the compilation.
Other Bits may be recognized by the machine dependant part of vbcc.
KNOWN PROBLEMS
Some known machine independant problems of vbcc at the moment:
- Some size limits are still hardcoded into the source.
- Switch statements are not optimized.
- Bitfields are not supported (they are always used as int) - this should
be ANSI compliant, however.
- No own preprocessor and some problems connected with this. E.g. in
error messages the name and line number of the preprocessor output
will be printed rather than the original source. Also there are
some cases where You cannot format Your source as freely as possible.
However You probably have rather strange style if You encounter this
problem.
- Inefficient source.
- The source is not strictly ANSI conforming (i.e. fully portable), yet.
E.g. there may be some external identifiers with more than 6
identical characters (haven't checked yet) and other problems.
- return of structures passes a pointer to a static object; I am not
sure if this is sufficient - this will probably be changed to pass
the address of the destination as a function argument.
- The scope of function parameters may be incorrect (will probably
only occur if struct/union/enum tags are defined within a prototype).
- Code for accessing volatile objects may not be generated if the result
is not used.
- Certain kinds of incorrect source may result in an infinite loop of
error printing or worse problems - some errors will probably have to
be changed to abort the translation.
THE FUTURE
- Bugfixing
- Builtin preprocessor. Someone is already working on this.
- Implementing an optimizer. This will be a rather large thing to do
and I will not start before vbcc seems stable.
- Certain features like register parameters.
- Other code generators.
- If You have any other ideas, tell me.
CREDITS (in descending alphabetical order, under work, not complete)
Frank Wille
Markus Schmidinger
Thorsten Schaaps
Joerg Plate
Joern Maass
Kai Kohlmorgen
Dirk Holtwick
Volker Graf
Matthias Fleischer
Thomas Dorn
Walter Doerwald
Lars Dannenberg
Michael Bode
Michael Bauer
Juergen Barthelmann
Thomas Arnhold
Volker Barthelmann volker@vb.franken.de
Kennedy-Ring 39
91301 Forchheim
Germany